Many computer file systems, are implemented using layers of abstraction including a virtual file system layer using vnodes. This is true for different variants of UNIX including HP-UX, AIX, and Solaris. FIG. 1 shows a file system 100 within a UNIX environment. These systems often lack a means to map or translate a vnode reference to the file name and its absolute path name.
At the top level, the file system provides a system interface for applications or network clients. This layer is shown in FIG. 1, which includes the system call (SYS_CALL) layer 110 and a Network File System (NFS) 160. The system call layer 110 provides a standardized interface for application programs (not shown). As a result, the underlying specifics of the file system can change or be replaced without requiring application modifications.
Below the system call layer 110 and the NFS 160 layer are one or more intermediate layers 105 below which lie the Virtual File System (VFS) layer 120. The VFS layer 120 references files by using vnode pointers. A vnode is a structure that represents a file in the file system 100. A vnode is created and used by the file system to reference a file. When a user attempts to open or create a file, if the VFS containing the file already has a vnode representing that file, a use count in the vnode is incremented and the existing vnode is used. Otherwise, a new vnode is allocated. Below the VFS layer 120 is the inode 130 layer. Inodes represent how files are organized on a disc drive 135.
Most operations within the file system 100 operate at the virtual file system layer and use vnodes or vnode pointers for file functions such as read, write, create, delete, and rename. Thus, extensions, modifications, or additions that hook into the file system 100, also need to operate on vnodes and or vnode pointers.
In this embodiment, the computer system 100 includes a Network File System (NFS) 160. The NFS 160 operates using NFS file handles or file identifiers (fids). Similar to the method by which file names are resolved into a vnode pointers, a file identifier or a NFS file handle for a file name is determined by determining the file identifier or NFS file handle for each directory and for the file name.
FIG. 2A is an example of prior art file system pseudo code 200 for resolving a file name “/user/foo/bar” 201 into a vnode pointer for a file delete operation. The pseudo code 200 is for illustrative purposes. Different operating systems, such as AIX, Solaris, and HP-UX can use different function names and calling parameters from the example shown in FIG. 2A.
In the first step 202, the file system root vnode pointer “rootvp” is used in the VOP_LOOKUP( ) operation to determine the vnode pointer for the “usr” directory name. In a second operation 203, the returned vnode pointer for the “usr” directory name is used by the VOP_LOOKUP( ) operation to determine the vnode pointer for the “foo” directory name. In a third operation 204, the returned vnode pointer for the “foo” directory name is used by the VOP_LOOKUP( ) operation to determine the vnode pointer for the “bar” file name. The returned vnode pointer “vp” is used for the delete operation 205, VOP_DELETE(vp).
Functions such as VOP_DELETE( ) are useful to monitor for file system enhancements such as applications that monitor or control file system changes. However, functions of interest, such as VOP_DELETE, operate on a vnode pointer and accordingly changes in the file system are not directly or easily reported or monitored using an associated file name and an absolute path name. The absolute path name is a string of characters that represents a file system object such as a file, directory, or link. The absolute path name is also referred to as a full path or fully qualified directory path.
When an NFS client (not shown) requests a file operation, the NFS 160 of FIG. 1 performs a set operations similar to the ones used by the system call interface 110. One difference is that the NFS 160 uses file identifiers (fids) or NFS file handles to operate on a file.
FIG. 2B illustrates the steps for determining the file identifier for the file /usr/foo/bar. The process 250 begins in the step 260 by looking up the fid for the first directory “usr” in the path name. From the root directory, a “root_fid” or “share_fid” is used as a known base point identifier for a file system. In the step 270, the fid returned for the “usr” directory is used in an NFS_LOOKUP( ) call to determine the fid for the “foo” directory. In the step 280, the fid returned for the “foo” directory is used in an nfs_lookup( ) call to determine the fid for the “bar” file. In the step 290, the returned fid is used for the file function NFS_DELETE(fid). The NFS_LOOKUP( ) and NFS_DELETE( ) functions represent pseudo code for the functions provided. The function names depend on the version of the UNIX operating system used. Similar steps can be used to resolve a NFS file handle.
FIG. 3 lists the types of information of interest 300 to an exemplary file change monitoring application that interfaces with the virtual file system. The application monitors and reports “who” 310, “what” 320, “where” 330, and “how” 340 a change is made. The “who” 310 is the login user name that made the change. The “what” 320 is the file name that was changed. The “where” 330 is the computer that made the change, and the “how” 340 is the name of the program that made the change. For determining the “who” 310, “where” 330, and “how” 340, there are known solutions. As described above, it is difficult to determine from a vnode the file name and absolute path name that changed. Applications monitoring file system changes need to operate or report events to an operator based on file names and absolute path names. Reporting changes based on vnodes would be meaningless to a person monitoring system changes. Accordingly, there is a need for the ability to translate a vnode, vnode reference, an NFS file handle or file identifier into an absolute path name.